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Structure of a DBMS 


¢ A typical DBMS has a 
layered architecture. 


¢ The figure does not show the 
concurrency control and 
recovery components. 


¢ This is one of several 
possible architectures; each 
system has its own 
variations. 
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Summary omy | QSaes 
¢ Transactions are important: 
¢ Concurrency 
¢ Recovery 
¢ Xact Properties 


ACID Properties 


Summary omen | (Sars 
¢ Transactions are important: 

¢ Concurrency 

¢ Recovery 
¢ Xact Properties 


/ Consistency 


- Data should be valid according to all defined rules 


Notion #1: Database Consistency Notion #2: Transaction Consistency 
DBMS logs all actions so that it can undo the The DBMS makes copies of pages modified 
actions of aborted transactions. by the transactions and transactions make 


changes to those copies. 


Summary oom: | QSaers 
¢ Transactions are important: 

¢ Concurrency 

¢ Recovery 
¢ Xact Properties 


Isolation 
Transactions do not affect each other 


Approach #1: Pessimistic Concurrency Control Approach #2: Optimistic Concurrency Control 

Avoid anomalies to happen Correct anomalies when they happen 

Example: Locking Examples: timestamp, multi-version, 
validation, snapshot isolation 


Most common approach to enforce serializability in DB because it is best for environments with high 
contention 


Summary open | QSaes 
¢ Transactions are important: 
¢ Concurrency 
¢ Recovery 
¢ Xact Properties 


> Atomicity | 


Each transaction is “all or nothing” 


Durability 


Committed data would not be lost, even after power failure. 


Approach #1: Logging Approach #2: Shadow Paging 
DBMS logs all actions so that itcan undo the The DBMS makes copies of pages modified by 
actions of aborted transactions. Most the transactions and transactions make 
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common approach. changes to those copies. 


Motivation 


¢ Atomicity: 
¢ Transactions may abort (“Rollback”). 
¢ Durability: 
¢ What if DBMS stops running? 
(Causes?) 
¢ Role of the recovery manager to 
ensure both 


¢ And rollback transactions that violate 
consistency 


O Desired Behavior after system restarts: 
- T2 &T3 should be durable. 


- T1,T4 &T5 should be aborted 
(effects not seen). 


crash! 
Abort | 
Commit | 
Commit l 
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Transactions/SQL eoteey | QB ues 
¢ SQL Basic Support: 


¢ BEGIN BEGIN 
¢ COMMIT INSERT INTO Boats (1,” Boughaz”,” blue”); 
¢ ROLLBACK (or ABORT) SAVEPOINT s1; 
© SAVEPOINT: INSERT INTO Boats (2,”Horizon”,” red”); 
¢ SAVEPOINT <savepoint_name> RELEASE SAVEPOINT s1: 
¢ Logical Rollback point in a Xact 
- RELEASE SAVEPOINT Ss ineracaval cds — | 
<savepoint_name> INSERT INTO Boats (3,”Titanic”,” white”); 
- Removes the named SAVEPOINT ROLLBACK TO s2; 
¢ ROLLBACK TO SAVEPOINT ” nw” ” 
<savepoint name> INSERT INTO Boats (4,”Flouga”,” blue”) 


* All statements since the named COMMIT; 
SAVEPOINT are aborted 
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¢ Concurrency control is in effect. 
¢ Strict 2PL, in particular. 
¢ Updates are happening “in place’. 


¢ |.e. data is changed in RAM (buffer pool) and data is overwritten on 
(deleted from) the disk. 


¢ A simple scheme to guarantee Atomicity & Durability? 
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Chapter 9 
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The BIG picture... 
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¢ Most database systems were originally designed for magnetic 
disks DBMS stores information on (“hard”) disks. 
¢ This has major implications for DBMS design! 
- READ: transfer data from disk to main memory (RAM). 
- WRITE: transfer data from RAM to disk. 


- Both are high-cost operations, relative to in-memory operations, so must 
be planned carefully! 


The Memory Hierarchy 
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Commodity Server 2020 CPU Die Ee Qs Shab 
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1K ns = 1 us, IM us = 1 ms = 
ep) 
L2 Cache a 
Access (100 ns), read IMB seq (3K ns) S 
Main Memory © 
ep) 
Seek (2 ms = 2M ns), read 1MB seq HDD (825K ns), read 1MB seq SSD (49K ns) ae 
© 
Cost is affected significantly by o) 
disk accesses ! Disk = 


Network: Send 2KB over commodity network (44ns), RTT in same DC (500K ns), RTT CA/MOR (29ms = 29M ns) 


Source: https://colinscott.github.io/personal_ website/research/interactive_latency.html _ 


Why Not Store Everything in Main Memory? wooaneny QS osr-c 


¢ Costs too much. One GB of RAM costs about 40.6 dhs, 
while 1 GB of (spinning) disk costs 0.6 dhs and 1GB of SSD 
costs 5 dhs [1]. 


“ \Viain memory is volatile. We want data to be saved 
between runs. (Obviously!) 
“- Typical storage hierarchy: 
= Main memory (RAM) for currently used data. 
= Disk for the main database (secondary storage). 
= Tapes for archiving older versions of the data (tertiary storage). 


[1] www.jumia.ma, 2022 


Jim Gray's Storage Latency Analogy: ——— 
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How Far Away is the Data — 


Jim Gray’s Storage Latency Analogy: 
How Far Away is the Data? 


Andromeda 
102 Tape /Optical \=s 2,000 Years | 
Robot . 
Jim Gray 
Turing Award 
10° Disk Pluto 2 Years 


: 15h 
100 Main Memory 


10 OnBoard Cache ~—~!his Campus 10 min 


2 OnChip Cache This Room 
1 Registers SP My Head 1 min 
(ns) 
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¢ Secondary storage device of choice. 
¢ Main advantage over tapes: random access vs. sequential. 
¢ Data is stored and retrieved in units called disk blocks or pages. 


¢ Unlike RAM, time to retrieve a disk page varies depending upon 
location on disk. 


- Therefore, relative placement of pages on disk has major impact on DBMS 
performance! 
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« The platters spin (say, mre 


« The arm assembly is 
moved in or out to position 
a head on a desired track. 
Tracks under heads make 


a cylinder (imaginary!). Platters 


« Only one head 
reads/writes at any 


one time. 
Arm assembly 


« Block size is a multiple 
of sector size (which is fixed). 
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¢ Data must be in RAM for DBMS to operate on it! 


¢ Buffer Mgr hides the fact that not all data is in RAM 
Page Requests from Higher Levels 


BUFFER POOL 

disk page 

free frame 
MAIN MEMORY 

GS 
DISK : : 
choice of frame dictated 
DB 


by replacement policy 
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¢ Buffer pool information table contains: 
<frame#, pageid, pin_count, dirty> 

¢ If requested page is not in pool: 

- Choose a frame for replacement 

Only “un-pinned” pages are candidates! 

- If frame is dirty, write it to disk 

- Read requested page into chosen frame 
¢ Pinthe page and return its address. 

* If requests can be predicted (e.g., sequential scans) 
pages can be pre-fetched several pages at a time! 
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¢ Requestor of page must eventually unpin it, and indicate whether 
page has been modified: 


° dirty bit is used for this. 
¢ Page in pool may be requested many times, 
¢ a pin count is used. 
¢ To pin a page, pin_count++ 
¢ A page is a candidate for replacement iff pin count == 0 (“unpinned”) 


«CC & recovery may entail additional I/O when a frame is chosen 
for replacement. 


¢ Write-Ahead Log protocol; more later! 
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¢ Requestor of page must eventually unpin it, and indicate whether 
page has been modified: 


° dirty bit is used for this. 
¢ Page in pool may be requested many times, 
¢ a pin count is used. 
¢ To pin a page, pin_count++ 
¢ A page is a candidate for replacement iff pin count == 0 (“unpinned”) 


«CC & recovery may entail additional I/O when a frame is chosen 
for replacement. 


¢ Write-Ahead Log protocol; more later! 
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¢ Simple, preferably without logging 
¢ Trivial Solution: No Steal/Force 


Back to Recovery: Simple Solution eee | (Baers 


¢ Simple, preferably without logging 


¢ Trivial Solution: No Steal/Force No Steal Steal 
¢ Dirty pages stay pinned in the buffer pool 
No ste?! . Cannot be stolen by replacement policy Force | Trivial 


¢ Locking at page level 
¢ During Commit: 


, No Force 
¢ Force dirty pages to disk 


a 
yce — 
¢ Unpin these pages in the buffer pool 


¢ Then commit 
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Back to Recovery: Simple Solution corey | QB anes 


¢ Simple, preferably without logging 
¢ Trivial Solution: No Steal/Force No Steal Steal 
¢ Dirty pages stay pinned in the buffer pool 


¢ Cannot be stolen by replacement policy 


¢ Locking at page level 
a 
— 


Force Trivial 


¢ During Commit: 
: , No Force 
¢ Force dirty pages to disk 
¢ Unpin these pages in the buffer pool 
¢ Then commit 


¢ Does this work? 
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¢ Simple, preferably without logging 


¢ Trivial Solution: No Steal/Force No Steal _ Steal 
2 Dirty pages stay pinned in the buffer pool 

oO a 

E * Cannot be stolen by replacement policy Force Trivial 

< ¢ Locking at page level 


¢ During Commit: 


, No Force 
¢ Force dirty pages to disk 


¢ Unpin these pages in the buffer pool 


Durability 


¢ Then commit 


¢ Does this work? 
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Back to Recovery: Simple Solution corey | QB anes 


¢ Simple, preferably without logging 
¢ Trivial Solution: No Steal/Force No Steal Steal 
¢ Dirty pages stay pinned in the buffer pool 


¢ Cannot be stolen by replacement policy 


¢ Locking at page level 
a 
— 


Force Trivial 


¢ During Commit: 
: , No Force 
¢ Force dirty pages to disk 
¢ Unpin these pages in the buffer pool 
¢ Then commit 


¢ Does this work? No! 
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¢ Simple, preferably without logging 
¢ Trivial Solution: No Steal/Force 


¢ Dirty pages stay pinned in the buffer pool 
¢ Cannot be stolen by replacement policy 
¢ Locking at page level 


Does not scale as we can run 
out of space in the buffer pool 


Does not support atomicity as a 


¢ During Commit: 
.£ 4 disk crash can happen after some 
orce dirty pages to dis (nor all) pages were forced to 
¢ Unpin these pages in the buffer pool disk 


¢ Then commit 
¢ Does this work? No! 
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¢ Most efficient Solution: Steal/No Force 
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¢ Most efficient Solution (also most complicated!): Steal/No Force 


¢ Need to handle atomicity 
¢ Problem: a Xact aborts after some of its pages got stolen (flushed to disk) 


ctea! + +Problem: Acrash happens before a Xact finishes 
¢ Solution: Must remember the old value of P at steal time (to support UNDOing the write 
to page P). 
¢ Need to handle durability 
rc& » Problem: A Xact commits but a crash happens before ts dirty pages being flushed to 
disk 
¢ Solution: Flush as little information as possible, in a convenient place, at commit time, to 
support REDOing modifications 


No F° 
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No Steal. Steal 


Simplest to implement | 
Least Efficient No UNDO 
FOrce No REDO 


No Force 
Hardest to implement 


Most Efficient 
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Other possible solutions 


No Steal Steal 
Simplest to implement aan ) 
Least Efficient 


. No UNDO UNDO 
Orc€ NoREDO § No REDO 


No Force No UNDO ~~ UNDO 


REDO ———— Hardest to implement 


Most Efficient 
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